Conventionally, optical networking equipment is provided by vendors (i.e., manufacturers, developers, etc.) to network operators which operate the equipment to realize various networking functions at Layers 0 (photonic), 1 (Time Division Multiplexing (TDM)), 2 (packet), etc. Optical networking equipment generally includes optical transceivers (modems), optical amplifiers, multiplexers/demultiplexers, Optical Power Monitors (OPMs), Wavelength Selective Switches (WSS), etc. Optical transceivers can provide data transmission using coherent modulation and polarization multiplexing techniques to achieve transmission in excess of 100 Gbps, the optical amplifiers (e.g., Erbium-Doped Fiber Amplifiers (EDFAs), Raman amplifiers, etc.) provide reach extension, the OPMs provide channel monitoring, the multiplexers/demultiplexers combine/split channels, and WSSs or other optical switches provide optical switching. A cornerstone of optical network operation is performance monitoring to ensure optimization as well as proper operation of the network. The conventional approach to performance monitoring includes each module monitoring various data points, performing some processing locally, and providing the results of the processing to an external system (external from the module such as a controller, Network Management System (NMS), etc.) such as via a backplane interface, a messaging bus, a Northbound Interface (NBI), etc. Also, the external system can also poll the module for information.
Importantly, there is a vast amount of Performance Monitoring (PM) data or other data (e.g., received symbols, corrected symbols, etc.) available for monitoring which may be captured on each optical module but the majority of which is not provided to the external system in most cases due to bandwidth limitations. For example, the bandwidth limitations are primarily based on a Northbound Interface between a network element (i.e., node or shelf which operates the module) and an orchestrator as the external system (e.g., controller, NMS, etc.), but the bandwidth limitations can also be based on the backplane in the network element for communication between modules, and the like. For example, in an optical network element with tens of transceivers or more, it is not possible to provide all captured optical measurement data to the external system. There is simply too much data. Data may be captured when certain trigger conditions are met. This data conventionally is captured in buffers and written to files, but the vast amount of data limits the number of events which can be stored before the oldest events are discarded, and the storage is overwritten. That said, processing of this data can provide insights, trends, etc. which could be advantageous for proactive performance monitoring and optimization of the optical network.
It would be advantageous to give users an opportunity to use this data as well as other data via user defined applications which execute on the optical modules themselves. However, functionality in the physical networking hardware is fixed by the vendor, and any new functionality must be provided in new product releases, through firmware updates, or via higher layer software platforms (NMS, Software Defined Networking (SDN), control plane, etc.). The higher layer software platforms cannot make use of this vast amount of data since it generally does not leave the module. Vendor implemented firmware updates are possible, but these are slow to implement and cannot account for all possible applications envisioned by the operators. There exists no technique today to provide end users (operators) the ability to execute user defined applications on the networking equipment itself.